Enterprise software systems are typically sophisticated, large-scale systems that support many, e.g., tens, hundreds or thousands, of concurrent users. Examples of enterprise software systems include financial planning systems, budget planning systems, order management systems, inventory management systems, sales force management systems, business intelligence tools, enterprise reporting tools, project and resource management systems, and other enterprise software systems.
One approach to enterprise software systems is to develop a custom user interface on top of custom hardcoded software (e.g., U.S. Pat. No. 8,191,052). In such an approach, the custom user interface has limited flexibility in terms of reports and data exploration, while the custom hardcoded software has insufficient performance when dealing with large volumes of data.
An alternative approach to enterprise software systems is the use of generic Business Intelligence, or BI, tools to interface, through zero or more software layers, with a multidimensional in-memory data store, an “OLAP” cube. The BI front-end “speaks” the language MDX; i.e., it transmits MDX expressions to the OLAP cube, which interprets the MDX and provides responsive query results to the BI front-end. Generic BI tools may be used to prepare and aggregate individual reports and analyses by executing queries on underlying data sources, and to present those reports and analyses to a user-accessible format such as a BI dashboard environment. However, the use of a generic BI tool does not provide “near real-time” performance when dealing with large volumes of data (where “near real-time” refers to the time delay introduced, by data processing and/or network transmission, between the occurrence of an event and the use of the processed data, such as for display).
As is known in the art, a relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model. The RDBMS provides an integrated set of computer software that allows users to interact with one or more databases and provides access to all the data contained in the databases (restrictions may exist that limit access to particular data). The RDBMS provides various functions that allow entry, storage and retrieval of large quantities of information and provides ways to manage how that information is organized. RDBMSs typically support queries expressed in Structured Query Language (SQL). On receiving an SQL query, an RDBMS traditionally creates a query plan to determine how the SQL query may be executed on one or more of the database tables to retrieve a result satisfying the query. The query plan identifies the one or more database tables which need to be accessed, the operations which need to be applied to the database tables (and often the data therein), and the order in which the operations must occur. A query plan can be optimized for certain parameters, typically to minimize query execution time and/or the total amount of data accessed. A query plan is executed to determine a query result, where “executed” is defined herein to include various forms of determining a query result from a query plan (e.g., query plan operators, implemented by functions, methods or other executable code, are executed, interpreted, etc.). In other words, a query plan (or query execution plan) generated for an SQL query in a relational database management system is an ordered set of operations to access and operate on tables (and often the data therein) from one or more databases managed by the relational database management system.
As is known in the art, a temporal database contains time-referenced, or time stamped, data records. A temporal-relational database includes temporal tables, where each such temporal table is to store data in data records. For each temporal table, the data records of that temporal table are each composed of a number of fields, one or more of which stores data and one or more of which stores timestamp(s) for that data record. Temporal tables are designed such that data records stored in the temporal tables are not overwritten. Rather, a change to data in a data record in a temporal table is performed by: 1) changing the timestamp of the data record which would otherwise have been overwritten or modified to reflect the time of the change; and 2) creating an additional data record that reflects the change. Because temporal tables capture the changes in their data records over time, a “delta” of the temporal table between two times can be determined. The data stored in the temporal table is sometimes referred to as the contents of the temporal table and is distinguishable from the schema of the temporal table. Taking a logical view, a temporal table can be thought of as a table with rows and columns, where a header of the table defines the schema of the table, each of the rows (which store the contents of the temporal table) is a data record, each intersection of a column and a row is a field of one of the data records, and one or more of the columns stores the above discussed timestamp(s). However, the contents of temporal tables may be stored in different ways (e.g., a “row-oriented” organization that mimics the above discussed logical view (sometimes referred to as “row-oriented” temporal tables), a “column-oriented” (also known as a “columnar”) organization (sometimes referred to as “column-oriented” or “columnar” temporal tables), etc.). Implementations of the typical relational database query plan operators (e.g., PROJECT, JOIN, SELECT) that operate on temporal tables are known in the art (e.g., D. Pfoser and C. S. Jensen, “Incremental Join of Time-Oriented Data,” In Proc. 11th Intl. Conf. Scientific and Statistical Database Management, pages 232-243, 1999; Jun Yang and Jennifer Widom, “Maintaining Temporal Views Over Non-Temporal Information Sources For Data Warehousing,” In EDBT '98 Proc. 6th Int. Conf. on Extending Database Technology: Advances in Database Technology, pages 389-403, 1998). Such implementations when applied on input temporal table(s) can sometimes determine and operate on just the “deltas,” thereby avoiding the need to re-execute operations on the totality of the data records in the temporal table(s). In the context of temporal-relational tables, a query plan (or query execution plan) generated for an SQL query by a relational database management system is an ordered set of temporal-relational operations used to access and operate on one or more temporal tables (and, often, the data therein) of one or more temporal-relational database(s) managed by the relational database management system.